Computerized systems and tools nowadays aid or control almost every aspect of human life, from typing documents to managing traffic lights. However, computerized systems are bug-prone, and thus require a testing phase in which the bugs should be discovered. The testing phase is considered one of the most difficult tasks in designing a computerized system. The cost of not discovering a bug prior to shipment or distribution of the computerized system to end-users or downstream manufacturers, for example, may be enormous, as well as even result in disastrous outcomes. For example, a bug may cause the injury of a person relying on a designated behavior of the computerized system. Additionally, a bug in hardware or firmware may be expensive to fix, as patching it requires call-back of the malfunctioned component. Hence, many developers of computerized systems invest a substantial portion of the development cycle to discover erroneous behaviors of the computerized system.
During testing phase, developers, verification engineers, QA staff members, and the like, test a newly developed design to verify that it operates properly. In some cases, test cases (also referred to simply as “tests”) may be devised to provide stimuli to the component, and enable testing whether its operation is correct (e.g., as expected). A first type of testing is pre-silicon verification. In this process, a design is simulated and tested in a virtual environment, thus providing the developer with high degree of observability, i.e. ability to see all signals in almost all times. On the other hand, the amount of cycles that can be generated during such simulations is fairly limited. A second type of testing is post-silicon verification, wherein tests are performed on actual physical implementation of the design (e.g., a chip after being taped-out from fabrication), in conditions up to scale with real-world systems such as ones commercially available. While post-silicon validation platforms are in orders of magnitude faster than any simulation, they suffer from low degree of observability, and the design is basically considered as a black box in this stage.
One approach to post-silicon verification is the use of exercisers. An exerciser is a unique type of a software based self-test that, once loaded to the system, continuously generates test-cases, executes them, and checks the results. The generated test-cases are required to be valid programs for the tested design to execute, as well as sufficiently complex so as to stress the design and trigger meaningful events in various areas. There are several types of checking mechanisms for post-silicon verification that are applicable in exercisers. One mechanism is design self-checks, which consist of in-place assertions causing a failure and are not specific to the software running at the time. Another mechanism is tool self-checks, using assertions in the verification tool itself (e.g., a value of a register X must be zero). Yet another mechanism is multi-pass consistency checks, wherein a test-case is run once and the architected results are saved. Then the test-case is run again for a number of times and the end-of-test results are compared to the result of the first pass. The premise of multi-pass consistency testing is that if the system under test functions correctly, the end-of-test results should be the same in all passes. Therefore an inconsistency detected is presumed to indicate a malfunction.